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Abstract. We describe an extension of Hoare’s logic for reasoning about 
programs that alter data structures. We consider a low-level storage 
model based on a heap with associated lookup, update, allocation and 
deallocation operations, and unrestricted address arithmetic. The asser¬ 
tion language is based on a possible worlds model of the logic of bunched 
implications, and includes spatial conjunction and implication connec¬ 
tives alongside those of classical logic. Heap operations are axiomatized 
using what we call the “small axioms”, each of which mentions only those 
cells accessed by a particular command. Through these and a number of 
examples we show that the formalism supports local reasoning: A speci¬ 
fication and proof can concentrate on only those cells in memory that a 
program accesses. 

This paper builds on earlier work by Burstall, Reynolds, Ishtiaq and 
O’Hearn on reasoning about data structures. 

1 Introduction 

Pointers have been a persistent trouble area in program proving. The main diffi¬ 
culty is not one of finding an in-principle adequate axiomatization of pointer op¬ 
erations; rather there is a mismatch between simple intuitions about the way that 
pointer operations work and the complexity of their axiomatic treatments. For 
example, pointer assignment is operationally simple, but when there is aliasing, 
arising from several pointers to a given cell, then an alteration to that cell may 
affect the values of many syntactically unrelated expressions. (See [20, 2, 4, 6] 
for discussion and references to the literature on reasoning about pointers.) 

We suggest that the source of this mismatch is the global view of state 
taken in most formalisms for reasoning about pointers. In contrast, programmers 
reason informally in a local way. Data structure algorithms typically work by 
applying local surgeries that rearrange small parts of a data structure, such as 
rotating a small part of a tree or inserting a node into a list. Informal reasoning 
usually concentrates on the effects of these surgeries, without picturing the entire 
memory of a system. We summarize this local reasoning viewpoint as follows. 

To understand how a program works, it should be possible for reasoning 
and specification to be confined to the cells that the program actually ac¬ 
cesses. The value of any other cell will automatically remain unchanged. 




Local reasoning is intimately tied to the complexity of specifications. Often, a 
program works with a circumscribed collection of resources, and it stands to 
reason that a specification should concentrate on just those resources that a 
program accesses. For example, a program that inserts an element into a linked 
list need know only about the cells in that list; there is no need (intuitively) to 
keep track of all other cells in memory when reasoning about the program. 

The central idea of the approach studied in this paper is of a “spatial con¬ 
junction” P * Q, that asserts that P and Q hold for separate parts of a data 
structure. The conjunction provides a way to compose assertions that refer to 
different areas of memory, while retaining disjointness information for each of 
the conjuncts. The locality that this provides can be seen both on the level of 
atomic heap assignments and the level of compound operations or procedures. 
When an alteration to a single heap cell affects P in P *Q, then we know that it 
will not affect Q; this gives us a way to short-circuit the need to check for poten¬ 
tial aliases in Q. On a larger scale, a specification {P}C{Q} of a heap surgery 
can be extended using a rule that lets us infer {P * R}C{Q * R}, which expresses 
that additional heap cells remain unaltered. This enables the initial specification 
{P}C{Q } to concentrate on only the cells in the program’s footprint. 

The basic idea of the spatial conjunction is implicit in early work of Burstall 
[3]. It was explicitly described by Reynolds in lectures in the fall of 1999; then an 
intuitionistic logic based on this idea was discovered independently by Reynolds 
[20] and by Ishtiaq and O’Hearn [7] (who also introduced a spatial implication 
P-*Q, based on the logic BI of bunched implications [11, 17]). In addition, 
Ishtiaq and O’Hearn devised a classical version of the logic that is more expressive 
than the intuitionistic version. In particular, it can express storage deallocation. 

Subsequently, Reynolds extended the classical version by adding pointer 
arithmetic. This extension results in a model that is simpler and more gen¬ 
eral than our previous models, and opens up the possibility of verifying a wider 
range of low-level programs, including many whose properties are difficult to 
capture using type systems. Meanwhile, O’Hearn fleshed out the theme of local 
reasoning sketched in [7], and he and Yang developed a streamlined presentation 
of the logic based on what we call the “small axioms”. 

In this joint paper we present the pointer arithmetic model and assertion 
language, with the streamlined Hoare logic. We illustrate the formalism using 
programs that work with a space-saving representation of doubly-linked lists, 
and a program that copies a tree. 

Two points are worth stressing before continuing. First, by local we do not 
merely mean compositional reasoning: It is perfectly possible to be compositional 
and global (in the state) at the same time, as was the case in early denotational 
models of imperative languages. Second, some aspects of this work bear a strong 
similarity to semantic models of local state [19, 15, 16, 13, 12]. In particular, 
the conjunction * is related to interpretations of syntactic control of interference 
[18,10,12], and the Frame Rule described in Section 3 was inspired by the idea of 
the expansion of a command from [19, 15]. Nevertheless, local reasoning about 
state is not the same thing as reasoning about local state: We are proposing 



here that specifications and reasoning themselves be kept confined, and this is 
an issue whether or not we consider programming facilities for hiding state. 

2 The Model and Assertion Language 

The model has two components, the store and the heap. The store is a finite 
partial function mapping from variables to integers. The heap is indexed by a 
subset Locations of the integers, and is accessed using indirect addressing [E\ 
where E is an arithmetic expression. 

Ints = {...,— 1,0,1,...} Variables = {x, y, ...} 

Atoms, Locations C Ints Locations D Atoms = {}, nil e Atoms 
Stores = Variables —*■ fi n Ints Heaps = Locations ~^fi n Ints 

States = Stores X Heaps 

In order for allocation to always succeed, we place a requirement on the set 
Locations: For any positive integer n, there are infinitely many sequences of 
length n of consecutive integers in Locations. This requirement is satisfied if we 
take Locations to be the non-negative integers. (In several example formulae, we 
will implicitly rely on this choice.) Then we could take Atoms to be the negative 
integers, and nil to be —1. 

Integer and boolean expressions are determined by valuations 
|P]s e Ints [B]s e {true, false} 

where the domain of s e Stores includes the free variables of E or B. The 
grammars for expressions are as follows. 

E,F,G ::= x,y, ... | 0 | 1 | E + F \ E x F \ E - F 

B ::= false \ B=>B\E = F\ E<F \ isatom?(P) | isloc?(P) 

The expressions isatom?(P) and isloc?(P) test whether E is an atom or loca¬ 
tion. 

The assertions include all of the boolean expressions, the points-to relation 
E 1-4 F, all of classical logic, and the spatial connectives emp, * and -* . 

P, Q,R ::= B \ E >-> F Atomic Formulae 

| false |P=><3|Va;.P Classical Logic 
| emp | P * Q | P-* Q Spatial Connectives 

Various other connectives are defined as usual: ->P = P => false; true = 
-.(false); P V Q = (-.P) => Q; P A Q = -.(-.P V -.Q); 3s. P = Fix. --P. 

We use the following notations in the semantics of assertions. 

1. dom(h) denotes the domain of definition of a heap h e Heaps, and dom{s) is 
the domain of s e Stores; 



2 . h#b! indicates that the domains of h and h' are disjoint; 

3. h * h! denotes the union of disjoint heaps (i.e., the union of functions with 
disjoint domains); 

4. (/ | z 1 —>■ j) is the partial function like / except that i goes to j. This notation 
is used both when i is and is not in the domain of /. 

We define a satisfaction judgement s, h (= P which says that an assertion 
holds for a given store and heap. (This assumes that Free(P) C dom(s), where 
Free(P) is the set of variables occurring freely in P.) 

s,h \= B iff [£?]s = true 

s. h\= E —> F ifr {{Ejs} = dom(h) and /i([P]s) = JFjs 
s,h\= false never 
s, h \= P => Q iff if s, h \= P then s, h (= Q 
s,h\=\/x.P iff Vv e Ints. [s | x i—> v], h \= P 
s,h \= emp iff h = [] is the empty heap 

s,h \= P * Q iff 3ho, hi. ho#hi, ho* hi = h, s,ho \= P and s, hi \= Q 
s,h \= P-* Q iff Vft'. if h'#h and s, h' |= P then s,h*h! \= Q 

Notice that the semantics of E i—> F is “exact”, where it is required that E is 
the only active address in the current heap. Using * we can build up descriptions 
of larger heaps. For example, (10 3) * (11 i-> 10) describes two adjacent cells 

whose contents are 3 and 10. 

On the other hand, E = F is completely heap independent (like all boolean 
and integer expressions). As a consequence, a conjunction (E = F) * P is true 
just when E = F holds in the current store and when P holds for the same store 
and some heap contained in the current one. 

It will be convenient to have syntactic sugar for describing adjacent cells, 
and for an exact form of equality. We also have sugar for when E is an active 
address. 

E —> /'o./•;, = {E^ F 0 )*---*(E + n^ F n ) 

E = F = (E = F) A emp 

= 3y.E^y (y /Free(F)) 

A characteristic property of = is the way it interacts with *: 

(E = F) * P & (E = F) A P. 

As an example of adjacency, consider an “offset list”, where the next node in 
a linked list is obtained by adding an offset to the position of the current node. 
Then the formula 

(iH»a,o)*(i + OHfi, — 6 ) 





describes a two-element, circular, offset list that contains a and b in its head 
fields and offsets in its link fields. For example, in a store where x = 17 and 
o = 25, the formula is true of a heap 


17 

a 

42 

b 

18 

25 

43 

-25 


The semantics in this section is a model of (the Boolean version of) the logic 
of bunched implications [11, 17]. This means that the model validates all the 
laws of classical logic, commutative monoid laws for emp and *, and the “parallel 
rule” for * and “adjunction rules” for -*. 

P=>Q R=>S 
P*R^Q*S 

P * R=> S P^R^S Q^R 
P => 7?-* S P*Q^S 

Other facts, true in the specific model, include 
((P i—> F) * (E' h-> F 1 ) * true) => E ^ E' emp <^> Vx. -i(x **-> - * true) 

See [21] for a fuller list. 

3 The Core System 

In this section we present the core system, which consists of axioms for commands 
that alter the state as well as a number of inference rules. We will describe the 
meanings for the various commands informally, as each axiom is discussed. 

There is one axiom for each of four atomic commands. We emphasize that 
the right-hand side of := is not an expression occurring in the forms x := [E] 
and x := cons (Pi,..., Ef-): [•] and cons do not appear within expressions. Only 
x := E is a traditional assignment, and it is the only atomic command that can 
be described by Hoare’s assignment axiom. In the axioms x, m, n are assumed 
to be distinct variables. 

The Small Axioms 

{E^-} [E\:=F{E^F\ 

{E i—► -} dispose(£’) {emp} 

{x = m}x := cons(ili, •••, Ek){x ** i?i[m/a;],..., E k [m/x\ } 

{x = n} x := E {x = (E[n/x])} 

{E i —> n A x = m} x := [E] {x = n A E[m/x] i—> n} 







The Structural Rules 


Frame Rule 


{P» { B}ewU} ““(C n FVee(/i) = {} 


Auxiliary Variable Elimination 


{P}C{Q} 

{3x.P}C{3x.Q} 


^Free(C') 


Variable Substitution 

{P\C{Q\ {xi . x k } 2 Fr ee(P,C,Q), and 

- Xi e Modifies(C) implies 

{{P}C{Q})[E 1 /x u ...,E k /x k \ E . i s a var i a ble not free in any other Ej 

Rule of Consequence 


P'^P {P}C{Q} Q^Q' 

{p'ycm 

The first small axiom just says that if E points to something beforehand (so 
it is active), then it points to F afterwards, and it says this for a small portion of 
the state in which E is the only active cell. This corresponds to the operational 
idea of [F] := F as a command that stores the value of F at address E in 
the heap. The axiom also implicitly says that the command does not alter any 
variables; this is covered by our definition of its Modifies set below. 

The dispose(F) instruction deallocates the cell at address E. In the post¬ 
condition for the dispose axiom emp is a formula which says that the heap is 
empty (no addresses are active). So, the axiom states that if E is the sole active 
address and it is disposed, then in the resulting state there will be no active 
addresses. Here, the exact points-to relation is necessary, in order to be able to 
conclude emp on termination. 

The x := cons(Fi,..., E k ) command allocates a contiguous segment of k cells, 
initialized to the values of E 1 ,..., E k , and places in x the address of the first cell 
from the segment. The precondition of the axiom uses the exact equality, which 
implies that the heap is empty. The axiom says that if we begin with the empty 
heap and a store where x = to, we will obtain k contiguous cells with appropriate 
values. The variable m in this axiom is used to record the value of x before the 
command is executed. 

We only get fixed-length allocation from x := cons(Fi,..., Ek). It is also 
possible to formulate an axiom for a command x := alloc(F) that allocates a 
segment of length E\ see [21]. 

We have also included small axioms for the other two commands, but they are 
less important. These commands are not traditionally as problematic, because 
they do not involve heap alteration. 







The small axioms are so named because each mentions only the area of heap 
accessed by the corresponding command. For [E] := F and x := [E] this is 
one cell, in the axioms for dispose or cons precisely those cells allocated or 
deallocated are mentioned, and in x := E no heap cells are accessed. 

The notion of free variable referred to in the structural rules is the standard 
one. Modifies (C) is the set of variables that are assigned to within C. The Mod¬ 
ifies set of each of x := cons(£d,..., E k ), x := E and x := [E] is {x}, while for 
dispose(P) and [P] := F it is empty. Note that the Modifies set only tracks 
potential alterations to the store, and says nothing about the heap cells that 
might be modified. 

In this paper we treat the Rule of Consequence semantically. That is, when 
the premisses P' => P and Q =>• Q' are true in the model for arbitrary store/heap 
pairs, we will use the rule without formally proving the premisses. 

The Frame Rule codifies a notion of local behaviour. The idea is that the pre¬ 
condition in { P}C{Q } specifies an area of storage, as well as a logical property, 
that is sufficient for C to run and (if it terminates) establish postcondition Q. 
If we start execution with a state that has additional heap cells, beyond those 
described by P, then the values of the additional cells will remain unaltered. We 
use * to separate out these additional cells. The invariant assertion R is what 
McCarthy and Hayes called a “frame axiom” [9]. It describes cells that are not 
accessed, and hence not changed, by C. 

As a warming-up example, using the Frame Rule we can prove that assigning 
to the first component of a binary cons cell does not affect the second component. 


{x i ► a} [x] := b {x b} 

{(x i-> a) 

*(x + 1hc)} 

[x] := 6{(x ~ 6) * (x + 1h c)} “““ 


{x i ^ a, c } 

[x] :=(){xh b, c} Syntactic Sugar 


The overlap of free variables between x + 1 c and [x] := b is allowed here 
because Modifies ([x] := b) = {}. 

4 Derived Laws 

The small axioms are simple but not practical. Rather, they represent a kind 
of thought experiment, an extreme take on the idea that a specification can 
concentrate on just those cells that a program accesses. 

In this section we show how the structural rules can be used to obtain a 
number of more convenient derived laws (most of which were taken as primitive 
in [20, 7]). Although we will not explicitly state a completeness result, along 
the way we will observe that weakest preconditions or strongest postconditions 
are derivable for each of the individual commands. This shows a sense in which 
nothing is missing in the core system, and justifies the claim that each small 
axiom gives enough information to understand how its command works. 

We begin with [E] := F. If we consider an arbitrary invariant R then we 
obtain the following derived axiom using the Frame Rule with the small axiom 






as its premise. 


{(£'- ) * i2} [E\:=F{(E~F) * R} 

This axiom expresses a kind of locality: Assignment to [A] affects the heap cell 
at position E only, and so cannot affect the assertion R. In particular, there is 
no need to generate alias checks within R. With several more steps of Auxiliary 
Variable Elimination we can obtain an axiom that is essentially the one from 
[ 20 ]: 


{3®!, • • •, x n . (E i-> -) * R} [E] := F {3®!, ■ ■ ■ ,x n .(E ^ F) * R} 
where xi,...,x„ ^Fr ee(E,F). 

For allocation, suppose x 4 Free(£d,..., E k ). Then a simpler version of the 
small axiom is 


{emp}x := cons(£d, ...,E k ){x ^ Ex, ...,E k } 


This can be derived using rules for auxiliary variables and Consequence. If, 
further, R is an assertion where x ^ Free (A) then 


{emp} x := cons(£'i, ...,E k ) {x ^ Ex, ...,E k } 

{emp * R} x := cons (E 1 ,..., E k ) {(x i-> Ex, ..., E k ) * R} 
{R}x := consul, ...,E k ) {(x Ex, ... ,E k ) * R} 


Frame 

Consequence 


The conclusion is the strongest postcondition, and a variant involving auxiliary 
variables handles the case when x e Free(A, Ex ,..., E k ). 

As an example of the use of these laws, recall the assertion (x i-> a, o)*(x+o i-> 
b, —o) that describes a circular offset-list. Here is a proof outline for a sequence 
of commands that creates such a structure. 


{emp} 

x := cons(a, a) 

{x i ► a, a} 
t := cons(6, b ) 

{(x b, b)} 

[x + 1] := t — x 
{(x i—^ d,t — x) ^ (t i—► b, 6)} 

[t + 1] := x - t 

{(x a,t — x) * (t b,x — t)} 

{3o. (xHa,o)*(x + OH(), -o)} 

The last step, which is an instance of the Rule of Consequence, uses t — x as 
the witness for o. Notice how the alterations in the last two commands are done 
locally. For example, because of the placement of * we know that x + 1 must be 
different from t and t + 1, so the assignment [x + 1] := t — x cannot affect the 
1 1 ► b, b conjunct. 






If we wish to reason backwards, then -* can be used to express weakest 
preconditions. Given an arbitrary postcondition Q, choosing (£ i-» F)-*Q as 
the invariant gives a valid precondition for [E] := F 


_ [E]:=F{E^F} _ 

{(£ ^ _) « ((£ ^ F)-* Q)} [E\ := F {(F » F) * ((F ^ F)^ Q)} 
{(E ~ -) * ((E ~ F)^ Q)} [E\ := F {Q} 


Frame 

Consequence 


The Consequence step uses an adjunction rule for * and -*. The precondition 
obtained is in fact the weakest: it expresses the “update as deletion followed by 
extension” idea explained in [7]. The weakest precondition for allocation can also 
be expressed with -* . 

The weakest precondition for dispose can be computed directly, because the 
Modifies set of dispose(F) is empty. 


{E i—> -} dispose(F) {emp} 

{(F i—> -) * R} dispos e(E) {emp * R} 
{(F - )*R } dispos e{E) {P} 


Frame 

Consequence 


The conclusion is (a unary version of) the axiom for dispose from [7]. 

The weakest precondition axiom for x := E is the usual one of Hoare. For 
x := [E] is it similar, using 3 to form a “let binder” (where n /Fr ee(E,P,x). 


{P[E/x]}x := E{P} 

{3n. (true * E i-> n) A P[n/x]}x := [F]{P} 


The formal derivations of these laws from the small axioms make heavy use of 
Variable Substitution and Auxiliary Variable Elimination; the details are con¬ 
tained in Yang’s thesis [24]. 

Another useful derived law for x := [E] is for the case when x 4 Free (A, R), 
y 4 Free (A), and when the precondition is of the form (F i—> y) * R. Then, 


{(E~y)*R}x:= [E]{(E»x)*R[x/y]}. 


5 Beyond the Core 


In the next few sections we give some examples of the formalism at work. In 
these examples we use sequencing, if-then-else, and a construct newvar for 
declaring a local variable. We can extend the core system with their usual Hoare 
logic rules. 

{PAB}C{Q} {PA^B}C'{Q} {PjCrjQ} {Q}C 2 {R} 

{P} if B then C else C'{Q} {P}C 1 \C 2 {R} 


{P}C{Q} 

{P} newvar x. C {Q} 


4Fvee(P,Q) 


We will also use simple first-order procedures. The procedure definitions we 
need will have the form 



procedure p[x i, x n \ y) 

B 

where xy, .... x n are variables not changed in the body B and y is a variable 
that is assigned to. Procedure headers will always contain all of the variables 
occurring freely in a procedure body. Accordingly, we define 

Modifies(p(a;i, ...,a;„; y)) = {y} 

Free(p(xi ,...,x n ;y)) = {xy, ...,x n ,y}. 

We will need these clauses when applying the structural rules. In the examples 
the calling mechanism can be taken to be either by-name for all the parameters, 
or by-value on the x^s and by-reference on y. 

Procedures are used in Section 7 mainly to help structure the presentation, 
but in Section 6 we also use recursive calls. There we appeal to the standard 
partial correctness rule which allows us to use the specification we are trying to 
prove as an assumption when reasoning about the body [5]. 

Our treatment in what follows will not be completely formal. We will continue 
to use the Rule of Consequence in a semantic way, and we will make inductive 
definitions without formally defining their semantics. Also, as is common, we will 
present program specifications annotated with intermediate assertions, rather 
than give step-by-step proofs. 

6 Tree Copy 

In this section we consider a procedure for copying a tree. The purpose of the 
example is to show the Frame Rule in action. 

For our purposes a tree will either be an atom a or a pair (ti,t 2 ) of trees. 
Here is an inductive definition of a predicate tree r i which says when a number 
i represents a tree r. 

tree a i <*==> i = a A isatom?(a) A emp 
tree (n, r 2 ) i 3 x,y. (i x,y) * (tree Tyx * tree r 2 y) 

These two cases are exclusive. For the first to be true i must be an atom, where 
in the second it must be a location. 

The tree r i predicate is “exact”, in the sense that when it is true the current 
heap must have all and only those heap cells used to represent the tree. If r has 
n pairs in it and s,h \= tree r i then the domain of h has size 2 n. 

The specification of the CopyTree procedure is 

{treerp} CopyTree(p; q ) {(treerp) * (treer «)}■ 


and here is the code. 





procedure CopyTree(p; q) 
newvar z, j, %' ,j '. 

{tree Tp} 
if isatom?(p) then 

{t = p A isatom?(p) A emp} 

{(tree Tp) * (tree rp){ 
q:=p 

{(tree Tp) * (treerg)} 
else 

{3T 1 ,T 2 ,x,y.T = (ti,t 2 ) *(p^ x,y)* (treen a;) * (tree r 2 y)} 

i : = [p]; j : = [p+ 1]; 

{3ti,t 2 .t = (ti,t 2 ) * (p i-> i, j) * (treen *) * (treer 2 j)} 

CopyTree(i; i')\ 

{3ti,t 2 .t = (ti,t 2 ) * (p i-> i,j) * (treen *) * (treer 2 j) * (treeni')} 
CopyTreefj; j'); 

{3n,r 2 .T = (n,r 2 ) *(pn i,j) * (tree n i) * (tree r 2 j) * (treeni') 

*(tr eer 2 f)} 

q := cons (i',f) 

{3ti,t 2 .t = (n,r 2 ) *(p^ i,j) * (treen i) * (treer 2 j) * (treeni') 

*(tree r 2 j') * (g i—» 

{(treerp) * (treerg)} 

Most of the steps are straightforward, but the two recursive calls deserve 
special comment. In proving the body of the procedure we get to use the speci¬ 
fication of CopyTree as an assumption. But at first sight the specification does 
not appear to be strong enough, since we need to be sure that CopyTree (i: i') 
does not affect the assertions p i—> i,j and tree r 2 j. Similarly, we need that 
CopyTr ee(j;j') does not affect treen*'- 

These “does not affect” properties are obtained from two instances of the 
Frame Rule: 

{tree n *} CopyTree(i; i') {(tree n i) * (tree n *')} 

{r = (n, t 2 ) *(pH i,j) * (treen «) * (treer 2 j)} 

CopyTree(i; i') 

{t = (n, t 2 ) *(pn i,j) * (tree n i) * (tree r 2 j) * (tree n i')} 

and 

_ {treer 2 j} CopyTree(j; j') {(tree r 2 j) * (treer 2 j')} _ 

{r = (n, t 2 ) *(pn i,j ) * (tree n i) * (tree t 2 j) * (tree n *')} 

CopyTree(j;y') 

{r = (n, r 2 ) *(pn i,j) * (tree n i) * (tree t 2 j) * (tree n i') * (tree r 2 j')}. 

Then, the required triples for the calls are obtained using Auxiliary Variable 
Elimination to introduce 3n,T 2 . (It would also have been possible to strip the 
existential at the beginning of the proof of the else part, and then reintroduce 
it after finishing instead of carrying it through the proof.) 



This section illustrates two main points. First, if one does not have some 
way of representing or inferring frame axioms, then the proofs of even simple 
programs with procedure calls will not go through. In particular, for recursive 
programs attention to framing is essential if one is to obtain strong enough 
induction hypotheses. The CopyTree procedure could not be verified without the 
Frame Rule, unless we were to complicate the initial specification by including 
some explicit representation of frame axioms. 

Second, the specification of CopyTree illustrates the idea of a specification 
that concentrates only on those cells that a program accesses. And of course 
these two points are linked; we need some way to infer frame axioms, or else 
such a specification would be too weak. 


7 Difference-linked Lists 

The purpose of this section is to illustrate the treatment of address arithmetic, 
and also disposal. We do this by considering a space-saving representation of 
doubly-linked lists. 

Conventionally, a node in a doubly-linked list contains a data field, together 
with a field storing a pointer n to the next node and another storing a pointer p 
to the previous node. In the difference representation we store n — p in a single 
field rather than have separate fields for n and p. In a conventional doubly-linked 
list it is possible to move either forwards or backwards from a given node. In 
a difference-linked list given the current node c we can lookup the difference 
d= n—p between next and previous pointers. This difference does not, by itself, 
give us enough information to determine either n or p. However, if we also know 
p we can calculate n as d + p, and similarly given n we can obtain p as n — d. 
So, using the difference representation, it is possible to traverse the list in either 
direction as long as we keep track of the previous or next node as we go along. 

A similar, more time-efficient, representation is sometimes given using the 
xor of pointers rather than their difference. 

We now give a definition of a predicate dl. If we were working with conven¬ 
tional doubly-linked lists then dlai • • • a n would correspond to 

1 f 

I I 

ai a n 


3 





Typically, a doubly-linked list with front i and back j' would satisfy the predicate 
dl a (i, nil, nil, j'). The reason for the internal nodes i' and j is to allow us to 
consider partial lists, not terminated by nil. 

A definition of dl for conventional doubly-linked lists was given in [20]. The 
main alteration we must make is to use 


a 


n-p 


instead of 


a 


n 


V 


to represent a node. 

Here is the definition. 

dl e (i, <*=*• emp A i = j A i' = j' 

dl aa k, k') 3 j.(i i —> a,j — i') * dla (j, i, k, k') 

We are using juxtaposition to represent the consing of an element a onto the 
front of a sequence a, and e to represent the empty sequence. As a small example, 
dl ab (5,1,3,8) is true of 


5 

a 

8 

b 

6 

8-1 

9 

3-5 


It is instructive to look at how this definition works for a sequence consisting 
of a single element, a. For dl a (i, i', j,j') to hold we must have 3 x.(i i-> a, x — 
i') * dl e (x, i, j, j')-, we can pick x to be j, as suggested by the i = j part of the 
case for e. We are still left, however, with the requirement that i = j', and this 
in fact leads us to the characterization i a,j — 0 A i = j’ of dl a (i, 

Thus, a single-lement list exemplifies how the e case is arranged to be compat¬ 
ible with the operation of consing an element onto the front of a sequence. The 
roles of the i = j and i' = j' requirements are essentially reversed for the dual 
operation, of adding a single element onto the end of a sequence. This operation 
is characterized as follows. 

dlaa(i,i',k,k') ^3f.dla(i,i',k',f) * k'b-*a,k-j' 

In the examples to come we will also use the following properties. 

j' ± nil A dla(i,nil, j,j r ) => 3/3, a, k. a = /3a* 

dl/3 (i,i’,j',k) * j' i-> a,j-k 
dla (/,/', j, nil) => emp A a = e A i' = nil A i = j 
dl a (nil, i',j, j'$ => emp A a = e A j = nil A i' = j' 







Doubly-linked lists are often used to implement queues, because they make 
it easy to work at either end. We axiomatize an enqueue operation. 

Rather than give the code all at once, it will be helpful to use a procedure 
to encapsulate the operation of setting a right pointer. Suppose we are in the 
position of having a pointer j', whose difference field represents pointing on the 
right to, say, j. We want to swing the right pointer so that it points to k instead. 
The specification of the procedure is 

{dice (i, nil setrptr (j,f, h, i){dl a (i,nil, k,j')}. 

Notice that this specification handles the a = e case, when j' does not point to 
an active cell. 

Postponing the definition and proof of setrptr for a moment, we can use it 
to verify a code fragment for putting an value a on the end of a queue. 

{dl a (front, nil, nil, back)} 
t := bach, 

{dl a (front, nil, nil, t)} 
back := cons(a, nil — £); 

{dl a (front, nil, nil, t) * back e-> a, nil — t} 
setrptr(nil, t, bach, front) 

{dl a (front, nil, back, t) * back i—> a, nil — t} 

{dl aa (front, nil, nil, back)} 

The code creates a new node containing the value a and the difference nil — t. 
Then, the procedure call setrptr(nil, t, bach, front) swings the right pointer 
associated with t so that the next node becomes back. In the assertions, the effect 
of back := cons (a, nil — t) is axiomatized by tacking *(back i—> a, nil — t) onto its 
precondition. This sets us up for the call to setrptr; because of the placement 
of * we know that the call will not affect (back i—> a, nil — t). More precisely, 
the triple for the call is obtained using Variable Substitution to instantiate the 
specification, and the Frame Rule with (back * a, nil — t) as the invariant. 
Finally, here is an implementation of setrptr(j, j’, k; i). 

{dl a (i, nil, j, j')} 
if j' = nil then 
{a = e A emp A f = nil} 
i := k 

{a = e A emp A j' = nil A i = k} 
else 

{3a! ,b,p. (a = a'b) * dla' (i, nil, j',p) * ( j* i—> b,j — p)} 
newvar d. d := \j' + 1]; \j' + 1] := k + d — j 
{3a',b,p. (a = a'b) * dla' (i, nil, j',p) * ( j' t—>b,k — p)} 

{dl a (i,nil, k, j')} 

The tricky part in the verification is the else branch of the conditional, where 
the code has to update the difference field of f appropriately so that k becomes 
the next node of j'. It updates the field by adding k and subtracting j; since 



the field initially stores j — p, where p is the address of the previous node, such 
calculation results in the value k — p. 

The use of the temporary variable d in the else branch is a minor irritation. 
We could more simply write \j' + 1] := k + [)' + 1] — j if we were to allow nesting 
of [•]. An unresolved question is whether, in our formalism, such nesting could 
be dealt with in a way simpler than compiling it out using temporary variables. 

Now we sketch a similar development for code that implements a dequeue 
operation. In this case, we use a procedure setlptrfi, . k; j'), which is similar 
to setrptr except that it swings a pointer to the left instead of to the right. 

{dl a (i, i'\ nil,/)} setlptr(i, i', k; /) {dl a ( i, k, nil, j')} 

The dequeue operation removes the first element of a queue and places its 
data in x. 

{dl aa (front, nil, nil, back)} 

{3n' . front i—► a,n' — nil * dl a (n', front, nil, back)} 
x := [front]; d := [front + 1]; n := d + nil; 

{x = a * front i—► a,n — nil * dl a ( n, front, nil, back)} 
dispos e(front); dispos e(front + 1); 

{x = a * dl a (n, front, nil, back)} 
setlptr(n, front, nil; back) 

{x = a * dl a (n, nil, nil, back)} 


This code stores the data of the first node in the variable x and obtains the 
next pointer n using arithmetic with the difference field. The placement of * 
sets us up for disposing front and front + 1: The precondition to these two 
commands is equivalent to an assertion of the form (front i—> a) * (front + 11—> 
n! — nil) * R, which is compatible with what is given by two applications of 
the weakest precondition rule for dispose. After the disposals have been done, 
the procedure call setlptr(n, front, nil; back) resets the difference field of the 
node n so that its previous node becomes nil. 

The code for setlptr (i,i',k;f) is as follows. 

{dl a (i, i’, nil, j 7 )} 
if i = nil then 
{a = e A emp A i = nil} 
j' := k 

{a = e A emp A i = nil A k = j’} 
else 

{3 a’,a,n. (a = aa 1 ) * dice' (n,i,nil,/) * (* 

[i+ 1] : = [i + M+i'-k 
{3a', a, n. (a = aa') * dl a ' (n, i, nil, j') * (i 
{dl a (i, k,nil, j')} 


a,n — i')} 
i—> a,n— k)} 



8 Memory Faults and Tight Specifications 


In this paper we will not include a semantics of commands or precise interpreta¬ 
tion of triples, but in this section we give an informal discussion of the semantic 
properties of triples that the axiom system relies on. 

Usually, the specification form { P}C{Q } is interpreted “loosely”, in the sense 
that C might cause state changes not described by the pre and postcondition. 
This leads to the need for explicit frame axioms. An old idea is to instead con¬ 
sider a “tight” interpretation of {P}C{Q}, which should guarantee that C only 
alters those resources mentioned in P and Q: unfortunately, a precise defini¬ 
tion of the meaning of tight specifications has proven elusive [1]. However, the 
description of local reasoning from the Introduction, where a specification and 
proof concentrate on a circumscribed area of memory, requires something like 
tightness. The need for a tight interpretation is also clear from the small axioms, 
or the specifications of setlptr, setrptr and CopyTree. 

To begin, the model here calls for a notion of memory fault. This can be 
pictured by imagining that there is an “access bit” associated with each location, 
which is on iff the location is in the domain of the heap. Any attempt to read 
or write a location whose access bit is off causes a memory fault, so if E is not 
an active address then \E\ := E' or x := [E] results in a fault. A simple way 
to interpret dispose(A) is so that it faults if E is not an active address, and 
otherwise turns the access bit off. 

Then, a specification {P}C{Q} holds iff, whenever C is run in a state satisfy¬ 
ing P: (i) it does not generate a fault; and (ii) if it terminates then the final state 
satisfies Q. (This is a partial correctness interpretation; the total correctness vari¬ 
ant alters (ii) by requiring that there are no infinite reductions.) For example, 
according to the fault-avoiding interpretation, {17 i—> -} [17] := 4 {17 i—> 4} holds 
but {true} [17] := 4 {17 i—> 4} does not. The latter triple fails because the empty 
heap satisfies true but [17] := 4 generates a memory fault when executed in the 
empty heap. 

In the logic, faults are precluded by the assumptions E i-> - and E n in 
the preconditions of the small axioms for [A] := E', x := [A] and dispose(A). 

The main point of this section is that this fault-avoiding interpretation of 
{P}C{Q} gives us a precise formulation of the intuitive notion of tightness. (We 
emphasize that this requires faults, or a notion of enabled action, and we do not 
claim that it constitutes a general analysis of the notion of tight specification.) 

The avoidance of memory faults in specifications ensures that a well- 
specified program can only dereference (or dispose) those heap cells guar¬ 
anteed to exist by the precondition, or those which are allocated during 
execution. 

Concretely, if one executes a program proved to satisfy {P}C{Q}, starting in a 
state satisfying P, then memory access bits are unnecessary. A consequence is 
that it is not necessary to explicitly describe all the heap cells that don’t change, 
because those not mentioned automatically stay the same. 




Fault avoidance in {P}C{Q} ensures that if C is run in a state strictly 
larger than one satisfying P, then any additional cells must stay unchanged; 
an attempt to write any of the additional cells would falsify the specification, 
because it would generate a fault when applied to a smaller heap satisfying P. 
For example, if {17 i-> -} C {17 i-> 4} holds then {(17 i-> -) * (19 i-> 3)} C {(17 i-> 
4) * (19 i—> 3)} should as well, as mandated by the Frame Rule, because any 
attempt to dereference address 19 would falsify {17 i—> -}C {17 i—> 4} if we give 
C a state where the access bit for 19 is turned off. (This last step is delicate, 
in that one could entertain operations, such as to test whether an access bit is 
on, which contradict it; what is generally needed for it is a notion which can be 
detected in the logic but not the programming language.) 


9 Conclusion 

We began the paper by suggesting that the main challenge facing verification 
formalisms for pointer programs is to capture the informal local reasoning used 
by programmers, or in textbook-style arguments about data structures. Part of 
the difficulty is that pointers exacerbate the frame problem [9, 1]. (It is only 
part of the difficulty because the frame problem does not, by itself, say anything 
about aliasing.) For imperative programs the problem is to find a way, preferably 
succinct and intuitive, to describe or imply the frame axioms, which say what 
memory cells are not altered by a program or procedure. Standard methods, such 
as listing the variables that might be modified, do not work easily for pointer 
programs, because there are often many cells not directly named by variables in 
a program or program fragment. These cells might be accessed by a program by 
following pointer chains in memory, or they might not be accessed even when 
they are reachable. 

The approach taken here is based on two ideas. The first, described in Section 
8 , to use a fault-avoiding interpretation of triples to ensure that additional cells, 
active but not described by a precondition, are not altered during execution. 
The second is to use the * connective to infer invariant properties implied by 
these tight specifications. 

The frame problem for programs is perhaps more approachable than the gen¬ 
eral frame problem. Programs come with a clear operational semantics, and one 
can appeal to concrete notions such as a program’s footprint. But the methods 
here also appear to be more generally applicable. It would be interesting to give 
a precise comparison with ideas from the AI literature [22], as well as with vari¬ 
ations on Modifies clauses [1, 8]. We hope to report further on these matters - 
in particular on the ideas outlined in Section 8 - in the future. (Several relevant 
developments can be found in Yang’s thesis [24].) 

There are several immediate directions for further work. First, the interaction 
between local and global reasoning is in general difficult, and we do not mean to 
imply that things always go as smoothly as in the example programs we chose. 
They fit our formalism nicely because their data structures break naturally into 
disjoint parts, and data structures that use more sharing are more difficult to 



handle. This includes tree representations that allow sharing of subtrees, and 
graph structures. Yang has treated a nontrivial example, the Shorr-Waite graph 
marking algorithm, using the spatial implication -* is used to deal with the 
sharing found there [23]. More experience is needed in this direction. Again, the 
challenging problem is not to find a system that is adequate in principle, but 
rather is to find rules or reasoning idioms that cover common cases simply and 
naturally. 

Second, the reasoning done in examples in this paper is only semi-formal, be¬ 
cause we have worked semantically when applying the Rule of Consequence. We 
know of enough axioms to support a number of examples, but a comprehensive 
study of the proof theory of the assertion language is needed. Pym has worked 
out a proof theory of the underlying logic BI [17] that we can draw on. But here 
we use a specific model of BI and thus require an analysis of properties special 
to that model. Also needed is a thorough treatment of recursive definitions of 
predicates. 

Finally, the examples involving address arithmetic with difference-linked lists 
are simplistic. It would be interesting to try to verify more substantial programs 
that rely essentially on address arithmetic, such as memory allocators or garbage 
collectors. 
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